Hi There, I would like hear from others how you have managed the Address Policies and automatic update? We are moving users from E2003 to E2007 and so far all our users have had automatic update "on", but when I made checks on our organization I have about 20 % of users, who will get the new primary addresses. But as E2003 does not force the policies, things are going so bad. Actually the number was even worst earlier, but I have been fighting with policies and got it better now. So if we move our users, 20 % of our users are unhappy. The solution is to disable the automatic update for them. But why to leave it on for others? Any arguments to not play like: 1. Create new mailbox and get addresses like EAP says 2. Disable the automatic update So we get the right addresses, but we get also option to change their addresses if required. For example when the email address is already used. How long time we have to wait until we can define own custom rules for the already existing email addresses. Just only sequence 1,2,3,4 might not be enough. Also if you change some user attributes, which are used for the EAP. E.g. you change the department name and that should change the address of the user from firstname.lastname@sales.company.com to firstname.lastname@markets.company.com. That will not happen until you touch the user with Exchange tools. But we still have ADUC for many different purposes (OCS), or 3rd part management tools. Some how I would like to see some statics of how others has defined this, and if there are many of us who has disabled the automatic update. Then we could put pressure on the MS site, that their EAP doesn't work. -- Petri

On Sun, 23 May 2010 00:19:06 +0000, Petri X wrote: >We are moving users from E2003 to E2007 and so far all our users have had automatic update "on", but when I made checks on our organization I have about 20 % of users, who will get the new primary addresses. But as E2003 does not force the policies, So it really ISN'T much of a policy then, is it? This is just one of the reasons many of use were so glad to see the earlier versions of the RUS disappear. >things are going so bad. Actually the number was even worst earlier, but I have been fighting with policies and got it better now. > >So if we move our users, 20 % of our users are unhappy. The solution is to disable the automatic update for them. But why to leave it on for others? Ask the question another way -- why is the information used by the policy to generate the addresses incorrect? If someone wants to be known as "Bob" and not "Robert" then why have "Robert" in the AD if nobody knows who that is? >Any arguments to not play like: > >1. Create new mailbox and get addresses like EAP says > >2. Disable the automatic update > >So we get the right addresses, but we get also option to change their addresses if required. For example when the email address is already used. How long time we have to wait until we can define own custom rules for the already existing email addresses. Just only sequence 1,2,3,4 might not be enough. > >Also if you change some user attributes, which are used for the EAP. E.g. you change the department name and that should change the address of the user from firstname.lastname@sales.company.com to firstname.lastname@markets.company.com. That will not happen until you touch the user with Exchange tools. But we still have ADUC for many different purposes (OCS), or 3rd part management tools. > >Some how I would like to see some statics of how others has defined this, and if there are many of us who has disabled the automatic update. Then we could put pressure on the MS site, that their EAP doesn't work. You can certainly script the creation of new mailboxes and disable the automatic generation of e-mail addresses. There's nothing worong with doing that if you have no policy at all about how e-mail addresses are formed or if your rules for forming e-mail address are more complex than can be expressed in the OPATH query (which is probably not true). Or perhaps you just need to reassess your current policy (or policies) and create some new rules? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, and thanks for your reply. > So it really ISN'T much of a policy then, is it? This is just one of > the reasons many of use were so glad to see the earlier versions of > the RUS disappear. This is funny argument and has been used quite often. But as I mention, modify user from some other way than Exchange tools, mailbox addresses are not "forced". So now the only change is that addresses will be updated when you modify your users by Exchange tools. So personally I would not like to call as a policy. > Ask the question another way -- why is the information used by the > policy to generate the addresses incorrect? If someone wants to be > known as "Bob" and not "Robert" then why have "Robert" in the AD if > nobody knows who that is? I would like to give votes to display name and other attributes on the user. If you need to contact to Robert and you find three of them, which one you pick up? I don't even know, why the SMTP addresses should be used in the company which is using the Exchange and AD. > There's nothing worong with > doing that if you have no policy at all about how e-mail addresses are > formed or if your rules for forming e-mail address are more complex > than can be expressed in the OPATH query (which is probably not true). > Or perhaps you just need to reassess your current policy (or policies) > and create some new rules? Of course when there has been multiple merges between companies the old addresses has been left to use. So that is of course one problem. But I should say, in the international company where is used local addresses the multiple policies are needed (we have maybe 18 now). One example, to resolve the problem with same names we could use initials to separate users. So we need two policies: One for firstname.lastname@company.com (for users who does not have any initials) second for: firstname.I.lastname@company.com (for users who does have initials) Then add let say five countries with the local addresses: Five for firstname.lastname@company.de/.it/.es/.fr/.us (for users who does not have any initials) Five more for: firstname.I.lastname@company.de/.it/.es/.fr/.us (for users who does have initials) And think about, some one should have .com, but also local address as a secondary. What about if we can use values from AD directly. Like now we can use firstname, lastname, and initials. But why not all of them? But as I mention, I would like to see what others thought about it.

On Sun, 23 May 2010 16:57:18 +0000, Petri X wrote: >Hi Rich, and thanks for your reply. >> So it really ISN'T much of a policy then, is it? This is just one of >> the reasons many of use were so glad to see the earlier versions of >> the RUS disappear. >This is funny argument and has been used quite often. It's not meant to be funny. >But as I mention, modify user from some other way than Exchange tools, mailbox addresses are not "forced". And they never have been. See my comment on being happy the earlier versions of the RUS are gone. >So now the only change is that addresses will be updated when you modify your users by Exchange tools. That's pretty much the way it's always worked -- except the "Exchange tools" that were supposed to make the modification was the Recipient Update Service. The ADUC didn't create any new addresses. >So personally I would not like to call as a policy. You'll have to if you want to refer to it as a "Recipient Policy", though. >> Ask the question another way -- why is the information used by the >> policy to generate the addresses incorrect? If someone wants to be >> known as "Bob" and not "Robert" then why have "Robert" in the AD if >> nobody knows who that is? >I would like to give votes to display name and other attributes on the >user. Okay -- but a Display Name can contain characters that are unacceptable in an e-mail address. And the Display Name is generated from the same data set that's used by the e-mail address generator. >If you need to contact to Robert and you find three of them, >which one you pick up? You'd be able to distinguish them by their surname, presumably; or by some other attribute. But my point wasn't how to disambiguate names, it was whether a "Robert" that everyone knows as "Bob" should have the given name in the AD of "Robert" or "Bob". The reason I use that is because your question was about having all or none of the e-mail addresses created by policy. >I don't even know, why the SMTP addresses >should be used in the company which is using the Exchange and AD. Because it's necessary to interoperate with other e-mail systems. And if you're going to do that, why not use the same addressing scheme for everything? >> There's nothing worong with >> doing that if you have no policy at all about how e-mail addresses are >> formed or if your rules for forming e-mail address are more complex >> than can be expressed in the OPATH query (which is probably not true). >> Or perhaps you just need to reassess your current policy (or policies) >> and create some new rules? >Of course when there has been multiple merges between companies the >old addresses has been left to use. So that is of course one problem. No, it's not. Generating a new email address creates a new primary proxy address. The previous primary proxy address s demoted to a secondary proxy address and remains, unchanged, in the user's property set. >But I should say, in the international company where is used local >addresses the multiple policies are needed (we have maybe 18 now). >One example, to resolve the problem with same names we could use >initials to separate users. So we need two policies: >One for firstname.lastname@company.com (for users who does not have >any initials) >second for: firstname.I.lastname@company.com (for users who does >have initials) >Then add let say five countries with the local addresses: Five for >firstname.lastname@company.de/.it/.es/.fr/.us (for users who does not >have any initials) >Five more for: firstname.I.lastname@company.de/.it/.es/.fr/.us >(for users who does have initials) >And think about, some one should have .com, but also local address >as a secondary. What about if we can use values from AD directly. >Like now we can use firstname, lastname, and initials. >But why not all of them? But as I mention, I would like to see what >others thought about it. It seems you've omitted the "You can certainly script the creation of new mailboxes and disable the automatic generation of e-mail addresses" part of my original answer. I sure wouldn't want to have someone trying to remember all the variations in your addressing schemes if you decide to manually assign e-mail addresses! --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP